Size Change: +68 B (0%)

Total Size: 1.2 MB

_{compressed-size-action}

Taking a look at this, I'm uncertain what benefit adding a search field provides for the block. @ntsekouras, I imagine that if a Query block is used on a search template (search.php) then the block would be passed the search parameter from the template and the block would only show those results.

I tested this and it works, but I'm not sure why I'd want to use this. When typing in a keyword, the list filters to show only posts with that keyword. I saw that it changed because the list changed. But what happens if the list doesn't change? How does the user know entering the keyword in the search field worked?

It seems to me like this use case should really be limited to categories, tags, taxonomies, etc. and not used in relation to a search field.

Here's my experience

Hey @mapk.

I imagine that if a Query block is used on a search template (search.php) then the block would be passed the search parameter from the template and the block would only show those results.

I'm not really sure yet how all these will come together eventually, but for now the the implementation still seems relevant. The search option was suggested as priority here: #24934 (comment).

How does the user know entering the keyword in the search field worked?

This is another matter to discuss that applies to every change in the Query block. It's not specific to search.

Thanks for reviewing @draganescu!

Design wise it is very bare-bones. It also makes little sens why search is in the block controls area and author is in the inspector controls area, both being filters.

Yes, I know, but there is a lot of discussions/iterations happening lately (related issue by @mapk ) about the design and I believe soon we will have some decisions to change the UI as well.

I'm still unclear on how search should work here. I just can't imagine this scenario.

I understand the flow for an end user to land on the archive.php page and be able to search the list. That would include a Search block on the page that communicated with the Query block though. Or a Search block that can be added inside the Query block. But for the block to contain a search field in its UI doesn't make sense to me.

@draganescu are you saying this ability should be purely programmatic? Should we remove any user facing UI for this?

I'm still unclear on how search should work here. I just can't imagine this scenario.

I think its base use case would be in any random page (homepage, any simple page etc..) that a user would like to have a list of posts with some keywords. The search query searches title, content etc.. and while it could be achieved with tags or something similar, it still remains a way for a user to have list of items which share something in common, the search term.

The front end outpout would not be a search text input. It remains a list of items (posts).